11章 オラクル
ブロックチェーンの文脈では
イーサリアムの外部の質問に答えることができるシステムのこと
理想的なオラクルは、トラストレス（trustless）
理想的なオラクルは、非中央集権の原理に基づき動作するため、信頼する必要がないということ
11.1 オラクルの必要性
EVM
非中央集権型のネットワーク内の任意のノード上でプログラムを実行
イーサリアムのステートを更新する
コンセンサスルールによる制約
コンセンサスを維持するために、EVMの実行は完全に決定論的
共有されたイーサリアムのステートと署名付きトランザクションのみに基づく
ここから導かれるものは・・・
EVMやスマートコントラクトが動作するための本質的なランダム源は存在しない
外部データはデータペイロードトランザクションとしてのみ導入される
ノードA
あるコマンドを実行して、結果としてストレージに3を格納する
ノードB
同じスマートコントラクトを実行して代わりに7を格納する
↑こうやって、ノードAとノードBは同じ文脈で全く同じコードを実行した
にも関わらず、最終的なステートは異なる
そのため、真のランダム関数が存在する場合、世界各地に独立して動作しているノードの集まりで構成されるネットワークが、最終的に達するステートが何なのかについて、分散した状態でコンセンサスに至る方法はないのです
コイントスゲームの問題
コインの裏表の出し方をランダムにする必要がある
マイナーは自分が勝つトランザクションだけをブロックに取り込むことができる
ランダム源
価格情報
天気情報
こういうものをトランザクションのデータに含めることができるが、信頼できない
この問題を直接解決するのを保留にして、オラクルを使うことになっている
11.2 オラクルのユースケースと使用例
オラクルは、外部の情報を得るためのトラストレスな方法を提供し、スマートコントラクトから使える
外部の情報とは
サッカーの試合結果
金価格
ランダムな数
みたいなもの
したがって、オラクルはオフチェーンの世界とスマートコントラクトの間のギャップを埋めるための仕組みと考えられます。
スマートコントラクトが実世界のイベントやデータに基づいて契約関係を執行できるようにすることで、その適用範囲は劇的に広がります。
しかしイーサリアムのセキュリティに外的なリスクをもたらす
資産分配のコントラクトの例
オラクルによって提供されるかもしれないデータ
量子・熱プロセスなどの物理的なソースを用いた乱数・エントロピー
自然災害の指標となる数値的要因
為替レート情報
資本市場データ
ベンチマーク参照データ
静的・準静的情報
時間と間隔情報
気象情報
政治イベント
スポーツイベント
測位情報
損害の検証
他のブロックチェーンで発生するイベント
イーサの市場価格
フライトの統計
（逆にオラクルで提供できないものって何だろう？）
11.3 オラクルの設計パターン
全てのオラクルはこんな機能を提供する
オフチェーンソースからデータを収集
署名されたメッセージ付きでデータをオンチェーンに転送
データをスマートコントラクトのストレージに入れることで利用可能な状態にする
オラクルのセットアップ方法
リクエスト−レスポンス型（request - response）
出版−購読型（publish - subscribe）
即時読み込み型（immediate - read）
即時読み込み型（immediate - read）
一番簡単
「この人は20歳以上か？」みたいな決定を即座にくだすために使える
お酒を買う人の年齢を確認したいときとか
ガス不要
出版−購読型（publish - subscribe）
定期的かつ頻繁に変化するデータのブロードキャストに使える
RSSフィード的なイメージ
オンチェーンのスマートコントラクトによるポーリングか、オフチェーンのデーモンで監視
webサーバーの世界ではポーリングは非効率だけどP2P環境ではそうじゃない
データ変更に対するポーリングは同期されたクライアントへのローカルコールに過ぎない
ガスを大量消費する可能性がある
リクエスト−レスポンス型（request - response）
これの実装は込み入ったものになる
実際の構成
オンチェーンスマートコントラクト
要求を監視しデータを検索して返すオフチェーンインフラストラクチャ
DAppからのデータ要求は複数のステップを含む非同期プロセスになる
オラクルの手順
DAppからクエリを受け取る
クエリを解析する
支払いとデータへのアクセス許可が提供されていることを確認する
オフチェーンソースから関連データを取得する（必要に応じて暗号化する）
データが含まれているトランザクションに署名をする
トランザクションをネットワークにブロードキャストする
通知など、さらに必要な任意のトランザクションを計画する
クライアントサーバーアーキテクチャみたいなもの
しかし他の方法もあるらしい
とにかくデータの種類や要件によって適切な方法を選ぶのが大事
11.4 データ認証
DAppが参照するデータソースそのものが信頼できると仮定しても、まだ解決すべき問題がある
オラクルとリクエスト−レスポンス型の仕組みが別で運営されてる場合に、その仕組みは信用できるか？という問題
転送中に改ざんされる可能性もある
データの整合性を検証できることが重要
データ認証の一般的な手法
真正性の証明（Authentictiy proofs）
データが改ざんされていないことを暗号学的に保証するもの
TEE（Trusted Execution Environment）
Oraclize
さまざまな真正性の証明を利用するオラクルサービス
TSLNotary証明
HTTPSでやりとりされるデータの真正性を保証する
Town Crier'
TEEアプローチに基づいた、認証されたデータを提供するオラクルシステム
ハードウェアベースの安全な独立領域を利用してデータが改ざんされていないことを保証する
11.5 計算オラクル
オラクルは任意の計算も実行できる
イーサリアムのガスリミットや計算コストを考えると特に有用な機能
Oraclizeが使える
サンドボックス化されたAWS仮想マシンで実行した計算結果を受け取れる
Dockerコンテナで実行するらしい
正しいDockerコンテナが実行されたか確認すればいい
これは本当に非中央集権化されたソリューションではない
検証可能であるオラクルの正しさを保証するためのもの
これにより、開発者はスマートコントラクトで使用するために、ポータブルで独立したプライベートなオラクルの正しさの保証に関するソリューションを得ることができます
TrueBit
より非中央集権型のソリューション
スケーラブルで検証可能なオフチェーン計算ソリューションを提供する
解決者と検証者がいるシステム
検証ゲームを行って、最終的にオンチェーンで検証結果に決定を下す
理論的には、この手法を用いることでスマートコントラクトはトラストレスにあらゆる計算タスクを安全に実行できるようになります。
11.6 非中央集権型オラクル
中央集権型のオラクルは多くのアプリケーションの要求を十分満たすが、イーサリアムネットワークの単一障害点になる
そのため非中央集権型オラクルも数多く提案されている
ChainLink
非中央集権型オラクルネットワークを提唱
以下で構成される
評判コントラクト、注文マッチングコントラクト、集約コントラクト
オフチェーンのデータ提供者レジストリ
非中央集権型オラクルにも課題がある
集約機能の体系化
SchellingCoinプロトコル
複数の参加者が値を報告し、中央値が「正しい」回答とみなされる
他社と同じ値を報告するようなインセンティブが与えられている
11.7 Solidityでのオラクルクライアントインターフェース
Oraclizeを使ってAPIからETH/USD価格を継続的に取得し、結果を格納するSolidityのコード例
コードが多いのでここは本を参照されたし
Oraclizeを使うためにはusingOraclizeを継承する（usingOraclizeはoraclizeAPIに定義されてる）
継承されたメソッドを使って色々やる
11.8 まとめ
オラクルは外部の事実をコントラクトの実行に持ち込む
オラクルを使うときには、信頼モデルを十分検討すること
hr.icon
次章！